Linux 基金会发布《开源软件供应链安全报告》
引言
随着网络安全事件的数量不断攀升、发生频率不断提高、后果越发严重，公共和私营行业都在聚焦同样的问题，即组织机构如何更好地管理当前现代互联世界带来的风险？
虽然有无数的战略、框架和“最佳实践”指南应运而生，但它们之间很少能步调一致而且其中有些互相矛盾，因此人们迫切需要就关于“软件供应链”做出尽职调查。
但即使是“软件供应链”这一术语本身也存在很多问题。究竟什么才算“软件”？谁是“供应商”？以及，可能更为重要的一点是，所谓的“软件供应链”由什么构成？
相比过去十年，现代软件开发的进程由于日益分散的性质而变得更加复杂。现在，自行编写多数软件的组织机构极其罕见，它们大多通过使用高质量和免费的开源软件 (OSS) 创建大量软件产品，而其专有软件要么作为“胶水”将各种 OSS 粘合在一起，要么成为OSS 之上的独特服务或功能。
因此，更恰当地讲，“软件”实际上可被理解为多种软件包的总和。进一步来讲，因为 OSS 不仅由个人甚至个体公司设计和编写，而且通常由数十个分散的开发人员一起完成，而软件“供应商”包括业余爱好者、数十亿美元公司等等不一而足。每个极其成功的开源项目都构建于开放框架的基础之上，软件工程师或其所在公司自愿贡献自己的时间提升项目的安全。围绕软件供应链的任何策略讨论都必须维护这个极其重要的开源贡献框架。
如此一来，“软件供应链”就已经非常纷繁复杂了。更加剧这种复杂性的一点是，供应链其它更具技术性的部分还具体牵涉软件是如何被存储、检索和分析的。虽然此前软件一般是在企业之间交付的，或由企业向客户交付，然而通过使用物理媒介如 CD 等，当前的软件（OSS和专有软件）更常被存储在“仓库”中并通过各种工具如通常被称为“软件包管理器”的项目依赖关系管理器 (PDMs) 从互联网被远程检索。
因此，软件供应链可被理解为包含如下多个部分：
2016年，由于对一个不相关的 OSS 软件包命名权存在争议，一个有名的开发人员从 npm 中删除了他们所有的 OSS 软件包。它的突然消失导致很多下游代码“崩溃”；2017年，攻击者使用和内置 Python 库名称“非常相似”的名称创建了多个恶意库；2018年，恶意软件包 “Colourama” 出现在 Python 软件仓库中窃取密币；2019年7月：热门 Ruby Gems 软件包的账户遭接管；2019年8月，一名未知恶意人员在流行的 Webmin 管理工具中安装了后门；2019年8月，11款 RubyGems 库被安后门。
频发的安全事件说明软件包管理器及仓库所使用的策略、进程和程序中内含的弱点。更糟糕的是，由于该供应链的元素是当前软件开发必不可少的，因此在几乎所有的情况下组织机构必须使用它们，因而面临一般而言超出控制范围的高风险。
软件供应链的最后一个元素是漏洞库，它虽然独立于软件供应链但却是它必不可少的一部分。然而，CVE 项目下，全球受依赖程度最高的漏洞追踪数据库“国家漏洞库”(NVD) 继续挣扎追赶于软件开发的增长、步调和复杂度。这些挣扎追赶直接影响依靠 CVE 和 NVD项目的开发人员和企业，并且也影响软件供应链整体的安全性和可靠性。
本文将探索当前影响软件供应链的安全性和可靠性问题，并找到从何处着手及如何改进软件供应链安全的方法。
软件供应链的检查
开发人员实践
在本文之前提到的图表中，开发人员被列为软件供应链中的第一环，是软件供应链最为依赖的元素。然而，出于多种原因，很多开发人员在开发软件时并未遵守应用程序安全最佳实践，如使用双因素或多因素认证机制，保护重要账户；要求项目在整个开发流程中支持变更控制追踪；在项目的开发生命周期中集成测试，检查常见的bug 和异常行为；追踪并修复新开发代码中或整合到既定项目中 OSS 依赖关系中的漏洞等。
仓库
如今多数软件开发吸收了互联网上免费的而且通常不设限的大量开源软件。虽然这类存储软件的确切来源可能各不相同，但很多开发人员都依赖于被称为“仓库”的软件存储站点。
然而，出于多种历史和经济原因，在很多情况下这些语言仓库缺乏甚至最基本的安全控制或质量控制机制。例如：很少有语言仓库可以提供检查存储代码目的的机制、系统地检查存储代码中是否存在漏洞或过时的软件包、具备供客户辨识存储代码是否衍生自其它代码的能力，薄弱的或缺少认证机制和发布者验证机制为存储代码来源带来了不确定性和风险，某些语言仓库包含限制性的最终用户许可协议(EULA)，限制尽责客户尝试自行对存储代码进行安全和质量分析。
至今没有一个仓库开发出解决全部问题的机制。另外，对于试图解决这些问题的某些语言仓库而言，很多通过“商业化”仓库本身的方式开展，为付费客户提供上述提到的这类“溢价”功能。因此，很多普通客户无法接触到很多基本的和必要的安全和质量检查服务。
项目依赖关系管理器（“软件包管理器”）
如今软件正在“一统天下”，要求软件用户、开发人员和维护人员使用直接而强大的工具，和业已且还在持续庞大的软件进行交互并对其进行有效的管理，其中最热门、使用最广泛的是“软件包管理器”如PDM，它大大降低了当代软件开发所必须的专业性和资源要求。然而，PDMs 只不过是软件检索工具，无法、或者当前并不存在可行方法来修改、检查所检索的软件是否具有已知的安全或可靠性问题、是否包含异常或恶意行为以及是否具有误导性软件包名称暗示“误植域名”，以及/或该名称是内置库的名称，或者没有实现许多防御措施如发布警报。
如牵涉 PDM 的安全事件越来越频发所证实的那样，当前程序所继承的弱点正成为热门的恶意利用通道。
漏洞数据库
如上所述，几乎可以肯定地说，当代“软件”是由很多软件包交织而成。软件社区在早期便意识到不可能严格执行内部漏洞追踪的任务，于是创建了通用漏洞披露系统 (CVE) 和国家漏洞数据库 (NVD) 项目。然而，近年来，这两个项目疲于追赶日新月异的新技术，从而导致并将继续导致涌现大量要求收录到 NVD 的请求。这种挣扎追赶引发了很多下游问题，包括：漏洞丢失或被拒、漏洞编号分配严重延迟、漏洞上下文描述说明单薄、漏洞评分虚高或过低、遭开发人员或工程师滥用、无法修复复杂漏洞等，从而导致 NVD 覆盖范围不完整、增加了漏洞缓解和管理的难度、引发漏洞“误报”、引发人们对项目的不信任等后果。
结果，很多依赖于 CVE 和 NVD 项目的利益相关者（包括几乎所有的现代企业、联邦机构等）无法了解完整的漏洞暴露情况。更糟糕的是，NVD 覆盖范围不全面导致虚假的安全表象：相关利益者认为，既然NVD 中不存在相关的 CVE 条目，那么他们的产品相对安全可靠。
最终用户实践
对于最终用户而言，他们与整体软件和具体的软件供应链的交互方式有两种。在很多情况下，最终用户将从提供商业支持的技术供应获得解决方案，他们可能永远不会做出关于选择 PDMs 或 OSS 软件包的决策。但其实最终用户拥有决策权，但很多人并未使用这种决策权：对购买要求的控制。例如，最终用户可能要求：
以健壮和透明的方式提供依赖关系列表、软件物料清单或其它类似组件追踪机制；
如由技术提供商维护的产品中出现具有特定影响的漏洞，则必须在特定的时间范围内修复它们；
开发人员必须将双因素或多因素认证机制应用于和所购买软件开发相关的任何账户上。
然而，还存在另外一种情况：最终用户选择通过开源软件包自行支持自己解决方案，这就要求最终用户能够应用本文“开发人员实践”部分提到的实践。另外，除了上述提到的这些实践和购买实践外，最终用户也可采取一些实际的步骤：检查并验证软件的可信性、从受信任来源下载软件、确保所请求的软件是所需软件、验证所收到的软件是所需软件，以及限制授予软件的权限以减少供应链问题产生的影响。不过，如下问题仍然存在，如难以确定软件是否可信、难以判断软件下载来源、难以确保所请求软件是正确的、以及缺乏安全和质量检查等。
最终用户无疑位于影响软件供应链的最好也是最差的位置。在上述两种情况下，他们必须意识到随着当代软件开发发生变化，他们也必须做出改变。
结论
现代软件开发是一个庞大的分发过程，“供应链”通常牵涉数十个（甚至数千个）个体开发人员、组织机构、软件片段以及将它们交织在一起的工具、策略和程序。虽然这种趋势（这种趋势只可能继续加强）降低了编程人员的准入门槛、缩短了产品的上市时间以及确保了国际社区的专业提升，从而创造了巨大的价值；但它同样留下了风险和被利用的隐患。
软件仓库、程序包管理器和漏洞数据库都是构成软件供应链的必要组件，而使用这些组件的开发人员和最终用户本身亦是如此。除非当前设计和程序中继承的弱点得到解决，否则它将继续为企业和开发人员带来重大风险。本文旨在强调软件供应链中的已知问题，并呼吁采取行动解决它们。Linux 基金会将召开全球应用程序和产品安全团队技术领导者会议，以期设计出能够解决这些问题的总体解决方案。
原报告请见：
https://www.linuxfoundation.org/wp-content/uploads/2020/02/oss_supply_chain_security.pdf
https://www.linuxfoundation.org/wp-content/uploads/2020/02/oss_supply_chain_security.pdf
题图：Pixabay License
本文由奇安信代码卫士编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 www.codesafe.cn”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。